In mobile or wireless networks, especially those that implement interactive services, such as web services, web browsing and the like, it is important to maintain low user-perceived latency (i.e., delay). Latency in the mobile network environment will typically negatively impact application performance and overall user satisfaction.
The mobile network is more prone to latency problems than a standard wireline network because wireless networks rely on a radio link that is characterized by low radio bandwidth (e.g., around 30 Kilobits per second (Kbps) usable bandwidth in a General Packet Radio Service (GPRS) connection). In addition, a significant latency is also introduced by the radio link layer that combats high bit error rates. The algorithms and implementation of underlying transport protocols further intensify the latency problem in mobile networks.
FIG. 1 provides an illustration of a conventional mobile network, in which a network proxy is implemented to gain access to the Internet. In this network 100 architecture the mobile terminal 110 is in radio communication with a network antenna 120. The network antenna is in communication with a network proxy 130 via the access network 140. The network proxy 130 acts as an intermediary between the mobile terminal and the Internet 150 to ensure security, administrative control, and caching service. The origin server 160 provides access to the web service or web page that the mobile terminal desires. This architecture is common in current and future mobile networks, such as a Wireless Application Protocol (WAP) gateway network, in which the network proxy serves as the gateway and translates information into Wireless Markup Language (WML). In such an architecture, any request from the mobile terminal goes to the origin server through this network proxy. However, even in mobile networks that do not implement a network proxy the problems related to latency are still prevalent due to low radio bandwidth, use of the radio link layer and other network factors.
Mobile Web Services (MWS) use HTTP/TCP/IP (HyperText Transfer Protocol/Transmission Control Protocol/Internet Protocol) for communication between the web service client and the service provider, which includes the radio link. In an attempt to control network congestion, TCP implements congestion avoidance and control algorithms. While these congestion avoidance algorithms are advantageous in the wireline communication network, studies have shown that these algorithms can be overly conservative, resulting in performance degradation and adding unwarranted latency into the data transmission process.
At the onset of communication between the network proxy and the client, TCP implements a congestion avoidance algorithm as a means of trying to eliminate or lessen congestion in the network. This algorithm is referred to as the “slow-start” algorithm and it attempts to efficiently allocate network resources by identifying underutilized network connections. The “slow-start” algorithm functions in the following manner. Upon receipt of the first communication from a terminal, the network proxy sets a congestion window. The congestion window indicates the maximum amount of data (i.e., the number of bytes) that can be sent out on a connection without being acknowledged (i.e, without an acknowledgement message being sent from the client). TCP detects congestion when it fails to receive an acknowledgement for a packet within the estimated retransmit timeout (RTO) period. Thus, when the network proxy fails to receive an acknowledgement from the client within the estimated timeout, the network proxy assumes that the data packet that it sent out was lost (i.e., dropped) and that the network is, therefore, congested. In this instance, the network proxy decreases the congestion window to one maximum segment size (MSS) and retransmits the data packet. Under other conditions, in which the network proxy receives an acknowledgement, it increases the congestion window by one MSS.
FIG. 2 illustrates the TCP message sequence between the client terminal and the network proxy and the implementation of the “slow-start restart”, in accordance with the prior art. For the sake of clarity, the TCP message sequence between the network proxy and the origin server is not addressed in FIG. 2. The communication between client and the network proxy server ensues at stage 200, when the client sends the network proxy a SYN request for establishing a connection. Upon receipt of this initial communication the network proxy server establishes an initial congestion window for the connection. In this example the congestion window is set to 956 bytes, which equates to one MSS. This means that, absent receipt of an acknowledgement from the client, the network proxy is allowed to send the client the minimum of the client's advertised window and its own congestion window.
At stage 210, the network proxy responds to the SYN request and, at stage 220, the client sends an acknowledgement to the network proxy. Since the network proxy received the acknowledgement within the estimated timeout period (referred to as the retransmit timeout period), the network proxy increases the congestion window by one MSS. In this example, the congestion window expands to two segments or 1912 bytes. Once the congestion window is expanded, absent receipt of an acknowledgement from the client, the network proxy is now allowed to send the client up to 1912 bytes (i.e., two segments).
At stage 230, the client sends the network proxy an HTTP request, which requests access to a specified web page and, at stage 240, the network proxy sends an acknowledgment to the client that the request has been received. In turn the network proxy, contacts the origin server to retrieve the web page for the client.
Once the network proxy server communicates with the origin server, at stage 250, the network proxy responds to the client with the requested web page or some other response from the origin server. It is noted that at stage 250, what is referred to in the art as the “slow-start restart” has occurred. The “slow-start restart” entails contraction of the congestion window if the TCP connection between the client and the network proxy remains idle for a period of time in excess of a timeout period (referred to herein as the second timeout period). In the example of FIG. 2, the congestion window has been contracted to one MSS, i.e., 956 bytes. The second timeout period will be implementation specific, and may be the round-trip time (RTT) or the retransmit timeout (RTO). TCP shrinks down the congestion window to one segment in fear of overwhelming the network in the absence of any knowledge of the current network conditions.
The “slow-start restart” concept was introduced in TCP communication to avoid sudden bursts of data into a network whose conditions are unknown because the connection has been idle for ‘too long’. However, the “slow-start restart” can unnecessarily throttle the performance of an already slow OTA (over-the-air) connection, even when there is no congestion on the network. Additionally, it is noted that in typical Mobile Web Services (MWS) communication the transmissions are typically short (only a few packets) and, as such, the TCP “slow-start restart” can severely limit the MWS performance.
There are numerous factors that can cause the TCP connection to remain idle for a long time. In one example, it may take the server a long time to reply to the client's request due to various reasons. One reason could be that the task the server needs to perform takes a lot of time (for example, it may need to request information from other servers and assemble the information to form the requisite reply). In another example, typically a network proxy first performs a Domain Name Server (DNS) query to map the domain name to servers on the Internet before contacting the origin server. Once the DNS query has been performed, the network proxy establishes a new TCP connection with the origin server, forwards the client's HTTP request and waits for the response before it can start sending any data to the client.
FIG. 3 illustrates the TCP message sequence between the client terminal and the network proxy in an instance in which the “slow-start restart” is not required because the idle period does not exceed the second timeout period. The FIG. 3 example illustrates that in instances in which the “slow-start restart” is averted; the overall delivery of data between the network proxy and the client occurs in less time, i.e., delays or latency in data delivery are prevented. In the FIG. 3 example the idle time (the time between the end of stage 230 and the beginning of stage 250) is less than the second timeout period and, therefore, the “slow-start restart” does not occur and the congestion window remains at its previous value, two segment lengths or 1912 bytes. Because the congestion window is not contracted, the subsequent transmission of data between the network proxy and client occurs with less round-trips than would be required if the window had been contracted. This is evident in the comparison of the FIG. 2 and FIG. 3 examples. The FIG. 2 example requires three round-trip transmissions, while the FIG. 3 example transmits the same amount of data in two round-trips. The effect on delivery time will be even more significant if the HTTP response (stage 250) is larger in byte size because the congestion window growth is faster in FIG. 3 than in FIG. 2. Thus, the FIG. 2 example, in which the “slow-start restart” is implemented, provides for greater delay or latency in the overall process of delivering data to the client.
Various different solutions have been proposed to overcome the latency problems related to the “slow-start restart” prevalent in TCP communications. While some of these solutions have been successful in addressing a portion of the latency problems attributable to “slow-start restart”, none of the known solutions address the problem related to idle time at the TCP sender. The following provides examples of some of the known solutions for overcoming latency problems related to “slow-start restart”.
Recently, it is becoming more common to implement a Performance Enhancing Proxy (PEP) within the network architecture to improve the performance of Internet protocols on networks where native performance is poor due to link characteristics. These PEPs can provide performance enhancements at various protocol layers. A transport-layer PEP has been suggested for mobile networks, which addresses the “slow-start restart” problem in situations where the mobile terminal experiences temporary disconnections (such as during handoffs). Such a transport-layer PEP is proposed in the article entitled “M-TCP: TCP for Mobile Cellular Networks”, K. Brown et al., ACM Computer Communications Review, Volume 27(5), October 1997. Although, the transport-layer PEP described in the article focuses on avoiding the “slow-start restart”, it does so in the context of data being available for delivery while the receiving device is not ready to receive it. As such, the transport-layer PEP does not address the problem of avoiding the “slow-start restart” when the receiving device is awaiting delivery of information but no data is available for transmission causing the idle time to exceed the timeout period.
Additionally, various methods have been implemented to that use probes to detect whether a connection is alive. For example, the TCP Keepalive option provides for probes to be sent to a client if the connection has been idle for a sustained period of two hours (this interval value is system-wide and any changes to this interval will affect all applications using TCP). The probe is usually an empty data packet (or a 1-byte packet) with a sequence number that is smaller than the receiver's expected sequence number. This forces the client to respond with an ACK, thus indicating that the connection is still alive. However, the TCP Keepalive option is used only to detect whether the other endpoint is still active and it performs such at a prolonged interval of two hours. In addition, the TCP Keepalive option does not detect network conditions or otherwise improve TCP performance.
A TCP Fast Start algorithm has been suggested, which provides a method for resuming data communication after long periods of idleness in the TCP connection. See “Addressing the Challenges of Web Data Transport”, V. N. Padmanabhan, PhD Thesis, University of California at Berkeley, September 1988. The proposed algorithm works in the following manner. After a long idle period, instead of performing ‘slow-start restart’, the sender uses the same value of congestion window as before the idle period and initiates the ‘fast start’ phase by sending out a burst of packets. Packets sent during the fast start phase are marked with a low priority so that if the network had become congested while the connection remained idle, the intermediate routers can simply drop the fast start packets. When a congested condition is detected, the algorithm falls back to the standard slow-start. Although this algorithm is capable of avoiding unnecessary “slow-start restarts”, it violates the congestion avoidance principles of TCP by sending a burst of packets into a network whose conditions are unknown.
Additionally, several solutions have focused on a proposal to have a ‘faster’ slow-start. An example is increasing the initial congestion window to two or four times the MSS. However, as it should be evident, these solutions are mere stop gate solutions, in that, the “slow-start restart” is still implemented in case the connection idle time exceeds the second timeout period.
The need exists to develop a method and application for avoiding the “slow-start restart” in TCP communications when network conditions dictate such. The methods and applications will characteristically eliminate latency in the network and, especially in a mobile or wireless network, improve web services performance. The desired solution shall address the problem of avoiding the “slow-start restart” when the receiving device is awaiting delivery of information but no data is available for transmission, resulting in the connection remaining idle for a period longer than the timeout. In addition, the desired solution shall be implemented while cognizant of current network capacity conditions. In this regard, the desired solution shall avoid the “slow-start restart” only if there is no current congestion within the network.